The Digital Video Broadcasting Handheld (DVB-H) standard defines a Multi-Protocol Encapsulation-Forward Error Correcting (MPE-FEC) data frame. An MPE-FEC frame is an organizational structure for data received by a mobile terminal or other device during a single time-slicing burst. As described in more detail below, an MPE-FEC frame includes two data tables. The first table holds application datagrams received during a burst of data. The second table holds error correction data (received during the same burst) that is used to correct errors in the application datagrams. The MPE-FEC frame is useful, e.g., in circumstances of high data packet loss. The MPE-FEC frame, which can be used in connection with video broadcast as well as other types of data, is generally described in European Telecommunications Standards Institute (ETSI) standard number EN 301 192 version 1.4.1 (titled “Digital Video Broadcasting (DVB); DVB specification for data broadcasting”). This standard, hereinafter referred to as EN 301 192, is available from ETSI at <http://www.etsi.org>.
The format of an MPE-FEC frame is shown in FIG. 1A. The first table in an MPE-FEC frame is an application data table (APDT). Application data in the APDT is typically (though not necessarily) being transmitted to a receiving device so as to provide some type of service to a device user. For example, the APDT data may be part of a video broadcast. The MPE-FEC frame is not limited to video broadcast, however, and the APDT table could be used to hold any type of data. For example, the APDT could hold data downloaded from the Internet, code for an application program being downloaded for installation on a mobile terminal, or any other type of data. The APDT is 191 columns wide, with the columns numbered 0 through 190.
The second table is a Reed-Solomon (RS) error correction data table (RSDT). The RSDT is 64 columns wide, with the columns numbered 0-63. The MPE-FEC frame (and thus the APDT and the RSDT) may have up to 1,024 rows. Each cell (i.e., each row/column intersection) of the MPE-FEC frame holds 8 bits (1 octet or byte) of data. The RSDT holds data which is used to correct transmission errors in the APDT data. As further explained below, the RSDT is filled (or partially filled) after the APDT has been filled (or partially filled and padded). Each row of data in the RSDT is then used to perform Reed-Solomon error correction on a corresponding row of the APDT.
FIGS. 1B-1E show how data is added to an MPE-FEC frame. Application data is transmitted to a mobile terminal (or other recipient device) in one or more data units known as a “datagram_section.” The format for a datagram_section is also defined by EN 301 192. Included in each datagram_section are one or more bytes of application data. ETSI EN 301 192 refers to each of these bytes as an “IP_datagram_data_byte.” A datagram refers to one or more application data bytes that are part of the same network layer (OSI layer 3) data frame. In the case of Internet Protocol data, a datagram is an IP datagram. A single datagram may span several datagram_sections, but will not (under EN 301 192) span multiple MPE-FEC frames. Also contained within a datagram_section (in fields labeled “MAC_address—4” through “MAC_address—1” by EN 301 192) are various “real-time parameters.” One of these real-time parameters is an 18-bit value used to address a cell in the APDT. The datagram_section further contains a CRC (cyclic redundancy code) for the entire datagram_section.
As a datagram_section is received, it is checked for errors using the CRC in that datagram_section. Each IP_datagram_data_byte in the datagram_section is then placed into its proper location in the APDT based on the address included in the real-time parameters. The APDT cells are numbered consecutively, beginning with the cell at the intersection of row 0 and column 0, and then progressing down each column. When the bottom of a column is reached, the numbering continues at the top (row 0) of the next column. Thus, the cell at the bottom row of APDT column 0 would have address x, and the cell at the top (row 0) of column 1 would have address x+1. The first IP_datagram_data_byte of each datagram_section is placed in the cell located with the address information provided in that datagram_section. The remaining IP_datagram_data_bytes in the datagram_section are then placed in the following cells. This is shown schematically in FIG. 1B. In FIG. 1B, a first datagram_section (“datagram_section 1”) for an MPE-FEC frame is received. The address in datagram_section 1, shown in decimal notation for convenience, is “0.” The address information is actually an offset value from a memory address for the row 0, column 0 cell in the receiving device's memory. Thus, the first IP_datagram_data_byte (“byte a”) in datagram_section 1 is placed in the APDT cell for row 0 and column 0. The remaining IP_datagram_data_bytes are then loaded into the succeeding cells. For simplicity, only three additional IP_datagram_data_bytes are shown in datagram_section 1 (“byte b” through “byte d”). However, a datagram_section may contain many more IP_datagram_data_bytes.
In FIG. 1C, the next datagram_section (datagram_section 2) is received. The address value in datagram_section 2 (“n”) indicates the APDT cell for the first IP_datagram_data_byte (byte w) in datagram_section 2. The remaining IP_datagram_data_bytes are then loaded into the following APDT cells. Although FIG. 1C shows all of the application data from datagram section 1 placed in column 0, this need not be the case. For example, a datagram_section may contain IP_datagram_data_bytes that continue into the next column. This is shown in FIG. 1D, where IP_datagram_data_bytes from subsequent datagram_sections 3 through N have been loaded into the APDT. Some of the datagram_sections may have failed the CRC check. In FIG. 1D, the contents of datagram_section 9 were found to contain errors (indicated by crosshatching). However, this erroneous data is still loaded into the APDT for later RS correction, as described below. In some cases, and as also shown in FIG. 1D, some of the APDT cells may contain padding, i.e., NULL data.
After all data for the APDT is received (the final datagram_section will contain a “table_boundary” flag), data for the RSDT is received. RS data is transmitted, during the same burst in which the application data is received, in structures known as MPE-FEC_sections. The format for an MPE-FEC_section is also defined by EN 301 192. Unlike datagram_sections, which can contain IP_datagram_data_bytes filling a portion of an APDT column (or spanning multiple columns), each MPE-FEC_section contains bytes of data (“rs_data_bytes,” not shown) for a single column of the RSDT. As seen in FIG. 1E, RS data is loaded into the RSDT, column-by-column, from successive MPE-FEC_sections. Although FIG. 1E shows the RSDT as completely filled, this will not always be the case. For example, some of the RSDT columns may be discarded (a procedure known as “puncturing”) in order to reduce the bandwidth needed for parity data (at the expense of error correction capability).
Once the MPE-FEC table is completed, and as shown in FIGS. 1F and 1G, error correction can begin. Reed-Solomon error correction is performed row-by-row on each row of the APDT. In particular, RS data in a row of the RSDT is used to correct errors in the corresponding row of the ASDT. This proceeds downward until errors in the entire ASDT have been corrected. As shown in FIG. 1H, the corrected application data is then be transferred from the APDT to the appropriate application program (e.g., a video playback application). The MPE-FEC table is also ready to receive application and RS data (datagram_sections and MPE-FEC_sections) in connection with the next transmission burst.
The previously-described process can present challenges under certain conditions. The receiving device must have sufficient memory to buffer the APDT and RSDT until errors in the application data have been corrected and the application data has been forwarded to its destination. If the receiving device has not completed error-correction processing of the MPE-FEC frame data for one burst when a subsequent burst arrives, the data for the subsequent burst must also be buffered until processing of the previous burst data is completed. Under EN 301 192, an MPE-FEC frame can hold almost 2 Mbits of data (1024 rows*255 columns*8 bits). Typically, DVB-H compliant receivers simply allocate memory blocks in sizes that are multiples of the largest MPE-FEC frame (˜2 Mbits). Received MPE-FEC frame data is then loaded into and processed from alternating ones of those multiple blocks. Because of physical device size constraints, however, memory is often limited in mobile terminals. Accordingly, a need remains for methods and systems reducing the memory space required to buffer data (such as MPE-FEC data) which may require (or be needed for) error correction.